The present invention relates generally to computing systems, and more particularly, to techniques for assuring thread rendezvous in an object-oriented computing environment.
In modern computing systems, often there is a need to suspend the execution of all threads. Typically, each thread of execution is suspended at a safe-point where all references (e.g., pointer types) used by the thread are known (“precisely known”). For example, all the pointers that reference an object should be known in case there is a need to move the object during garbage collection where objects may be moved in memory. In general, thread rendezvous at a safe-point is needed for synchronization of all threads. As such, thread rendezvous is crucial to various applications (e.g., modern garbage collection applications).
Conventionally, polling is used to achieve thread rendezvous where a polling code (or instruction) is generated at a number of critical points in the code. Every time a polling code (or instruction) is executed by a thread of execution, a determination is made as to whether there is a need (or a request pending) for all threads of execution to rendezvous (i.e., suspend execution until all other threads have been suspended). If there is a request for thread rendezvous, the thread is suspended at the point in the code where the polling was executed. The thread is suspended until all other threads have also suspended their execution (i.e., thread rendezvous).
Although polling can effectively be used to achieve thread rendezvous, polling requires a significant amount of computing resources. The significant amount of computing resources is needed because, among other things, each polling code (or instruction) requires more than four (4) or five (5) Central Processing Unit (CPU) cycles.
A relatively more efficient technique for assuring thread rendezvous is “code patching.” Instead of generating polling code, “code patching” dynamically writes (or patches code) with an “unconditional stop” instruction. The “unconditional stop” instruction is dynamically written (or patched) in a number of critical points in the code where it would be polled, but unlike polling, the “unconditional stop” instruction is “patched” only when there is a request for thread rendezvous. In other words, under normal circumstances, there is no “unconditional stop” instruction. The “unconditional stop” instruction is dynamically written (or patched) only when there is a need for polling. The execution of each thread is suspended as soon as the “unconditional stop” instruction is encountered. When all threads have been suspended and thread rendezvous has been achieved, the “unconditional stop” instructions can effectively be taken out of the code. When there is a need for thread rendezvous, the code can be patched again with the “unconditional stop” instruction at various points of execution to assure that the thread will suspend.
Although “patching” is relatively more efficient than polling, it can not be used, among other things, for “read-only” code. “Read-only” code requires that the code remain unchanged. However, “patching” requires modifying the code. Hence, polling techniques are conventionally used to achieve thread rendezvous when code is implemented as “read-only.” However, as noted above, polling is not as efficient as “code patching.”
It should also be noted that “read-only” code has many applications. Modern computing systems (e.g., virtual machines) require some code to be implemented as “read-only” code. By way of example, “read-only” code is used in computing systems (e.g., virtual machines) that perform ahead-of-time compilation, or systems that use process cloning to implement a variety of functions (e.g., application startup). “Code patching” cannot be used for read-only code and polling uses a significant amount of resources. Thus, there is a need for more efficient techniques that can be used to assure thread rendezvous for “read-only” code.
Accordingly, alternative methods for assuring thread rendezvous are useful.